home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1390 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.1 KB
  1. Date: Tue, 10 May 94 01:39 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: So many cookies
  5.  
  6.  
  7. Is anyone working on the system cookie jar function/s that were mentioned?
  8. If not, then I recently came up with something I may test out (no reason
  9. to hack it into the kernel to test it actually).  What is a good gemdos #
  10. to use for a cookie function?
  11.  
  12. Also, it occured to me that only root should be able to make or delete a
  13. system cookie (I know, kinda pointless if they can use Super() and do it
  14. anyway).  I've really got cookies on my mind since I was playing with file
  15. cookies when the system cookie jar functions were mentioned.   I've got
  16. 2 days off so I'm gonna hack a little.
  17.  
  18. How about making Super() and Supexec() a root-only <<would this be euid==0?>>
  19. function once the system cookie calls are in place.  Or, better yet, here's
  20. a new idea .....
  21.  
  22. how about a new domain where Super() and Supexec() are root-only, Fsfirst()
  23. and Fsnext() are not available (should use dopendir, etc), Dgetdrv and Dsetdrv
  24. are not available (everything should be accessed from U:), Dgetpath is
  25. unavailble (should use Dgetcwd()) and the BIOS and XBIOS calls are not
  26. available (should use /dev/ filesystem).  Otherwise, the domain acts like
  27. MiNT domain only you can't change back to normal TOS or standard MiNT domain
  28. (which completes the security).  This would allow us to have a "Unix" domain
  29. where a remote shell would be started in this new Domain and you get a secure
  30. system after that (gotta figure out what to do about GEM, make AES and VDI
  31. root-only for this domain).  I think this would be the best situation.
  32. TOS for backward compatibility, MiNT domain to use the flexibility of the
  33. new calls, and a third domain that is more Unix-like that removes some of the
  34. TOS calls and improves protection.  You can have all three domains running
  35. at once, but the system is safe if remote users are started in the new domain.
  36.  
  37. It's an idea, anyway.   Here's 2 more ideas.  If it were possible to specify
  38. a file size during Fcreate, then file systems could use this information
  39. to allocate space on the hard drives more efficiently, and ramfs could allocate
  40. memory more efficiently.  I stole this idea from OS/2, and it makes sense.
  41. It would make a good optional parameter or a new call perhaps.
  42.  
  43. Last idea - memory mapped files (this idea stolen from NeXT/Mach).  In VM
  44. systems, you have to save a page to disk if an application puts data in it.
  45. if you had a memory mapped file, you don't save a page to disk if that page
  46. belongs to the memory mapped file - the page isn't marked as being written
  47. to when the OS reads the file data onto the block.  That way, your swap file
  48. is kept small and you save alot of write operations.  To swap the page back in
  49. you just read from the original file.  You have to use lots of MMu tricks for
  50. this, but ideally, you open the file and get a pointer, not a handle.  The
  51. pointer accesses the file as if you called Malloc and Fread and read everything
  52. in from disk but the Os handles how much to read in.  If you write into the
  53. block, then the page is marked as written and if it gets swapped, then it is
  54. written into its file, NOT the swap file.  When the file is closed it's like
  55. doing an Fwrite and an Mfree too, all changes are flushed to the file.
  56.  
  57. You get a nicer interface to the process of reading and writing files and the
  58. OS decides how many pages it should keep in memory if the file size is greater
  59. than system RAM.  If another application needs memory, then the memory mapped
  60. file's pages can be given to another application without saving them (assuming
  61. the app hasn't written to the memory, only the OS has).  All can be done with
  62. the MMU.  Think of fonts, GIFs, programs like LESS and VI that use parts of
  63. large files.  Even program code can be better managed through a memory mapped
  64. file than the standard swap file because its already on disk .. why write it
  65. twice?
  66.  
  67. Anyone like these ideas, or should I just go away :-)  Everyone else posts
  68. code not ideas, so I feel like I'm justing wasting bandwidth with talk.
  69. Anyway, email me.  
  70.  
  71. CYA
  72. Evan Langlois
  73. ekl@sdf.lonestar.org
  74.  
  75.